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ABSTRACT 

We present a non-null annotations inferencer for the Java 
bytecode language. We previously proposed an analysis to 
infer non-null annotations and proved it soundness and com- 
pleteness with respect to a state of the art type system. This 
paper proposes extensions to our former analysis in order 
to deal with the Java bytecode language. We have imple- 
mented both analyses and compared their behaviour on sev- 
eral benchmarks. The results show a substantial improve- 
ment in the precision and, despite being a whole-program 
analysis, production applications can be analyzed within 
minutes. 

Categories and Subject Descriptors 

F.3.2 [Logics and Meanings of Programs]: Semantics 
of Programming Languages — program analysis; D.3.3 [Pro- 
gramming Languages]: Language Constructs and Fea- 
tures — Data types and structures; D.1.5 [Programming 
Techniques]: Object-oriented Programming 

General Terms 

Languages, Theory, Experimentation 

Keywords 

Static analysis, NonNull, annotation, inference, Java 

1. INTRODUCTION 

A common source of exceptional program behaviour is the 
dereferencing of null references (also called null pointers), re- 
sulting in segmentation faults in C or null pointer exceptions 
in Java. Even if such exceptions are caught, exception han- 
dlers represents additional branches which can make verifi- 
cation more difficult (bigger verification conditions, implicit 
flow in information flow verification, etc.) and disable some 
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optimizations. Furthermore, the Java virtual machine is 
obliged to perform run-time checks for non-nullness of refer- 
ences when executing a number of its bytecode instructions, 
thereby incurring a performance penalty. 

As a solution, Fahndrich and Leino proposed a type sys- 
tem [10] to partition references between those which may 
contain the null constant and those which may not. The 
user had to annotate the program with non-null types which 
was not practical in the case of legacy code. We proposed a 
formal definition of this type system [TJ)], proved its sound- 
ness and provided a whole-program dataflow analysis to infer 
those annotations. 

The contribution we present is the tool NIjJj (Nullabil- 
ity Inference Tool), an implementation resulting from our 
provably sound analysis. This analysis had been designed 
on a relatively high level language, well suited for the def- 
inition of the analysis and the proofs but too far from the 
target language of the implementation: the Java bytecode. 
After recalling the sound analysis this paper is based on, we 
describe the improvements we have brought to the former 
analysis. We then present the implementations of both anal- 
yses and compare the results of the two implementations on 
practical benchmarks. 

2. A SOUND INFERENCE ANALYSIS 
2.1 Non-Null Annotations 

The main difficulty in building a precise non-null type sys- 
tem for Java is that all objects have their reference fields set 
to null at the beginning of their lifetime. Explicit initial- 
ization of fields usually occurs during the execution of the 
constructor, potentially in a method called from the con- 
structor, but it is not mandatory and a field may be read 
before it is explicitly initialized — in which case it holds the 
null constant. We consider a field that has not been explic- 
itly initialized during the execution of the constructor to be 
implicitly initialized to null at the end of the constructors. 

Figures QJa) shows a class C while Fig. [2] shows a model 
of the lifetime of an instance of class C. Assume no other 
method writes to C.f. The first part of the object's lifetime 
is the execution of the constructor, which is mandatory and 
occurs to all objects. The field f is always explicitly ini- 
tialized in the constructor and never written elsewhere, so 
any read of field f will yield a non-null reference. Despite 
that, if an annotation must be given for this field valid for 
the whole lifetime of the object, it will have to represent the 
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class C { 
SNullable Object f; 
C(){ 
this.f = new ObjectO; 

} 

@Nullable Object m(@NonNull C x){ 

return x . f ; 
} 
} 

(a) Too Weak Annotations 



class C { 
@NonNull Object f; 
C(){ 

m(this) ; 

this.f = new ObjectO; 
} 



class C { 
SNonNull Object f; 
CO{ 

m(this) ; 

this.f = new ObjectO: 
} 



@NonNull Object m(@NonNull C x){ @Nullable Object m(@Raw C x){ 

return x.f; return x.f; 

} } 

} } 



(b) Motivation for @Raw Annotations 
Figure 1: Motivating Examples 



(c) @Raw Annotations 
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Figure 2: Lifetime of an Object 



non-null reference put in the field by the constructor, but 
also the default null constant present at the beginning of 
the object's lifetime. Such an annotation is basically @Nul- 
lable where we would have clearly preferred a more precise 
information, such as @NonNull. The solution is to consider 
that annotations on fields are only valid after the end of the 
constructor, during the rest of the object's lifetime. The 
ONullable annotations can now be replaced with ONonNull 
annotations. 

Figure QJb) shows the same class where ONullable an- 
notations have been replaced and a call to the method m 
has been added to the constructor. The method m simply 
reads and returns the value of f . Although this method is 
not a constructor, the object x may still be in its construc- 
tion phase, i.e. the constructor of the object from which 
the field is read may not have been fully executed, and the 
value actually read may be null in contradiction with the 
field annotation. In fact, for each variable, we need to know 
whether the reference may point to an object that is still in 
its construction phase. We annotate with @Raw such vari- 
ables. As the invariant described by the annotations is not 
yet established during the object initialization, reading a 
field of an object annotated as ©Raw may return a null value 
(SNullable) whatever is the annotation on the field. The 
example in Fig. QJb) has been corrected in Fig. [TJc). 

We refine those @Raw annotations by indicating the set 
of classes for which a constructor has been executed. An- 
notations concerning fields declared in those classes can be 
considered as already valid despite the fact the initializa- 
tion of the object is not yet completely finished. The set 
of classes for which a constructor has been executed can be 
represented by a single class as the execution order of the 
constructors is constrained by the class hierarchy. 

2.2 Sound Inference 

One of the key ideas behind non-null annotation inference 
is to track field initialization in constructors and methods 
called from constructors. At the end of constructors, all 



fields defined in the current class which might not have been 
explicitly initialized are annotated with @Nullable while all 
other fields are annotated with the value they have been 
initialized with. 
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Figure 3: Grammar of the Idealized Language 

In [16], we chose to formalize and prove our analysis on 
a language close to the bytecode but without an operand 
stack. This trade-off came from the fact that we planed an 
implementation at the bytecode level but removing the stack 
avoided to deal with alias information, which simplified the 
presentation and the proofs. Figure [3] shows the grammar 
of the idealized language. 

To build our provably sound inference analysis we defined 
an abstract domain State" and a constraint based specifica- 
tion of the analysis that constrain S" E State" depending on 
a program P (denoted by S" \= P). To prove the soundness 
of the analysis we completed several tasks. 

• We defined concrete domains and a concrete semantics 
for the language. 

• We explained how to interpret State" in terms of con- 
crete values with the relation ~ C State" x State. 

• We defined the property safe([P]) which holds if all 
accessible states of the program P are safe (but [P] is 
not computable in general). 

• We defined the property safe'(S') which holds if S" 
enforces safe(|PJ) (assuming S" admits the states of 
[P] as conservative interpretation, i.e. VS E [P].(S" ~ 
S)). 

• Finally, we proved the soundness, i.e. we proved that 
if S" is a solution of the constraint system for the pro- 
gram P (S 8 |= P) and if safe" (S 8 ) holds, then safe([P]) 
holds. (safe^S 8 ) A S 8 |= P =>• safe([P])) 



Val = Loc + {null} 

Object = F ^ Val x {def , undef } 

Local Var = V -> Val + {±} 

Heap = Loc — >> Object x C x p(C) 

State = (N x LocalVar x Heap) + 

Figure 4: Concrete Domains 



In the following, we will first give some details about the 
concrete and abstract domains and the relation between 
them. Then, we will show some examples of constraint rules 
of the analysis. 

2.2. 1 Concrete and Abstract Domains 

The concrete domains are the domains manipulated by 
the operational semantics of the language. Their definitions 
in Fig. [4] are standard except for two particular additions. 
In order to reason about object and field initialization, we 
instrumented the semantics and the domains so 1) each field 
of each object has a flag which indicates if the field has been 
(explicitly or implicitly) initialized, and 2) the set of classes 
for which a constructor has been executed is attached to 
each object. This addition is used to prove the correctness 
of the refinement of the @Raw annotation. 

Figure [5] presents the abstractions of the concrete do- 
mains. The Val domain represents the annotation described 
in Sect. 12.11 references are either abstracted with NonNull, 
Nullable or Raw. Figure [5] also gives the correctness rela- 
tions for Val" , which express how to interpret Val" in terms 
of concrete values. The first rule defines Nullable as T, 
i.e. Nullable abstracts any value. The second rule defines 
NonNull as an abstraction of references to objects that have 
all their fields initialized. The third rule defines Raw - as 
an abstraction of any non-null value. Finally, the forth rule 
defines Raw(^4) as an abstraction of references to objects 
that have all their fields defined in A or super-classes of A 
initialized. 

The Def" domain is used by TVal" to represent the ini- 
tialization state of the fields of the current object (this in 
Java) that are defined in the current class. At the begin- 
ning of the object's lifetime, the abstraction of the current 
object T* G TVal" associate to each field defined in the cur- 
rent class the abstract value UnDef. The abstraction then 
evolves as fields are initialized. The reason for limiting the 
information to fields defined in the current class (and not 
to all fields of instances of the current class) is to keep the 
checker modular and annotations easy to understand by a 
developer. The abstraction used for the heap does not differ- 
entiate objects and is flow-insensitive. This is quite standard 
and corresponds to the purpose of the analysis, i.e. giving 
one annotation for each field. As the annotations must be 
easy to read, they are context-insensitive, but, to achieve 
some precision, the analysis is inter-procedural and method 
signatures are inferred from the join of the calling contexts 
(as in 0-CFA US]). A method signature includes the ini- 
tialization state of the fields of the current object (this) and 
an abstract value for each parameter (args). A method sig- 
nature also represents the result of the method, i.e. the 
fields that are initialized at the end of the method (post). 
The analysis has been designed without return values but 



adding them is straightforward. Those domains are then 
combined to form the abstract state that correspond to all 
reachable state of the program. To be able to use strong 
updates [4], i.e. to precisely analyse assignments, the ab- 
stractions of the local variables and the current object are 
flow-sensitive while, as discussed earlier, the abstraction of 
the heap is flow-insensitive. 

2.2.2 Constraint based dataflow analysis 

The analysis computes S" £ State" such that S" |= P, i.e. 
S" over-approximates all reachable states of the program P. 
We have specified this property as a constraint based data 
flow analysis. Expressing the analysis in terms of constraints 
over lattices has the immediate advantage that inference can 
be obtained from standard iterative constraint solving tech- 
niques for static analyses. 

To simplify the rules, we denote by M,H,T\L" a value 
of State". The main rule of the analysis is Rule (1) given in 
Fig. [5] The first two constraints of this rule state that an- 
notations on method arguments are contravariant, i.e. the 
lower in the hierarchy the less precise is the annotation. It 
is standard in object oriented languages as a virtual call to 
a method in a top-level class may dynamically be resolved 
to a call in one of its sub-classes. The third constraint is 
conversely implied by the covariance of the method post- 
condition (post). The next two constraints link the method 
signatures with the flow-sensitive information used by the 
intra-procedural part of the analysis. Finally, the last line 
constrains the state depending on all instructions of the pro- 
gram using a judgment of the form 



M\H\T\U (= (m, 



mstr 



for when the abstract state M,H\T,L" is coherent with 
instruction instr at program point (m,i). The two other 
rules are examples of such judgements. [_] 

Rule (2) corresponds to the instruction that sets the field 
/ of the object stored in the local variable x to the value 
of the expression e. The local variables are unchanged by 
such an instruction and the abstraction of the expression 
e is computed ([e] ) and added to the possible values of 
/. Then, depending on whether x is this or not, the flow- 
sensitive information T" may be updated to reflect the fact 
that a field of the current object has been initialized. 

The judgment for the return instruction is given in Rule (3) . 
If the instruction is found in a constructor then the abstrac- 
tion of the null constant (Nullable) is added to all fields that 
are not labeled as initialized at the end of the constructor. 

3. TOWARDS A JVML ANALYSIS 

In [TB] , we presented a first prototype of the analysis and 
some features that were mandatory to target the Java byte- 
code language (JVML). The prototype already had a simple 
must-alias analysis to track the references to this in the 
stack and some other conservative features. This section 
proposes three modifications of the analysis on the JVML. 

The JVML is a stack language and includes some in- 
structions to test variables for the null constant, such as 
if null n which pops the top of the stack and jumps n bytes 
of instructions if the popped reference is null. From such an 
instruction, the analysis infers that, when the test fails, the 
popped value is non-null but this information is useless to 



The complete judgment set can be found in [16] 



Val" = {Raw", NonNull, Nullable} 

U {Raw(F) | Y G Class} 
Def" = {Def, UnDef} 
TVal" = F -* Def" 
Heap" = F -» Val" 
LocalVar" = V -> Val" 
Method" = M -» {jthis e TVal"; args £ (Val")*; post G TVal" J 
State" = Method" x Heap" x (M x N ->■ TVal") 
x (M x N -* Local Var") 



V G Val 



Nullable ~h v 

v G dom(ft) V/ £ dom(/i(«)),IsDef(/i(«)(/)) 

NonNull ~h u 

u 7^ null 

Raw - ~^ « 
V/ € UA^c fields (^)' I sDef(fe(«)(/)) 



i) G dom(/i) 



Raw(A) 



•^ W 



Figure 5: Abstract Domains and Selected Correctness Relations 
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Figure 6: Some Constraint Based Rules 



load x i4 Nullable 

ifnull n x H> NonNull 
load x x H> NonNull 



Figure 7: Recovering Information from Tests 



the analysis as this value cannot be reread. For the infor- 
mation to be exploitable, the analysis must know to which 
local variable the popped value was equal to. To infer equal- 
ities between stack and local variables we have implemented 
a must-alias analysis. For example, in Fig. [7] assuming x 
is annotated as @Nullable at the beginning, this allows to 
infer that the second load loads a non-null (@Raw) value. 



Assume we have two functions a G 2 



Val" and 



7 G Val" — > 2 Val which computes the abstraction of a set of 
concrete values and the concretization of an abstract value, 
respectively. In Fig. [7] assume that x is either non-null and 
fully initialized or null at the beginning of the example. The 
analysis abstracts such a value by 

NonNull U a ({null}) = Nullable. 

The test allows to recover some information but, as Nullable 
also abstract raw references, the most that can be recovered 



a(7(Nullable) \ {null}) = Raw . 

Such configurations often occur in real programs as implic- 
itly initialized fields are always annotated with Nullable, de- 



spite they may never contain any raw value. To solve this, 
we add Nullablelnit, a new abstract value that abstract val- 
ues that may not point to raw objects. We have 

NonNull C Nullablelnit C Nullable 
a(7(NullableInit) \ {null}) = NonNull . 

It allows to annotate more references as @NonNull and there- 
fore to gain in precision as field annotations can then be 
trusted. It also allows a more direct gain in precision. A 
variable annotated as ©Nullablelnit may not point to an 
object that is not fully initialized, so field annotations can 
also be trusted when reading fields of variables annotated 
with ONullablelnit. 

The JVML includes the instanceof C instruction which 
pushes 1 on the stack if the top of the stack is non-null and 
is an instance of the class C, otherwise it pushes 0. A condi- 
tional jump generally occurs few instructions after. Recover- 
ing information from such an instruction is not trivial: both 
the instanceof instruction and the jump are needed, they 
may be separated by some other instructions, and they inter- 
act in the concrete semantics through integer values. To be 
able to use this information, we have defined another anal- 
ysis which computes an abstraction of the stack such that, 
for each stack variable, it contains an under-approximation 
of the set of local variable that must be non-null if the cor- 
responding stack variable is equal to 1. 

Finally, when a possibly null value is dereferenced, if the 
control flow reaches the next instruction it means that, at 
this point, the reference is non-null. Therefore, it is pos- 
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sible to refine all instructions that dereference variables so 
those variables are inferred as non-null on outgoing non- 
exceptional edges of the control flow graph. 

4. IMPLEMENTATION 

The global inferencer is a whole program analysis com- 
posed of three analysis: the alias analysis, the analysis of 
instanceof instructions and the main non-null analysis de- 
scribed in this paper. The non-null analysis uses the re- 
sults of both the alias and the instanceof analyses and 
the instanceof analysis uses the results of the alias anal- 
ysis. Those communications between the analyses impose 
the simple scheduling of running first the alias analysis, then 
the instanceof analysis and in the end the non-null analy- 
sis. The three analyses have been implemented in a similar 
standard fashion. First we iterate over all instructions of the 
program to build transfer functions that take as argument 
a part of the abstract state and that return the parts of the 
abstract states that have been modified by the instructions. 
We store the functions in a hash-map with their dependen- 
cies as keys and we apply a work list algorithm to compute 
the fixpoint. The result of each analysis is the fixpoint com- 
puted. 

The global result contains, for each program point, three 
abstractions, one of which, the non-null abstraction, con- 
taining already a lot of information. Such an analysis can- 
not be implemented without taking care of memory con- 
sumption. We have done the implementation in OCaml [3T] 
so we have been able to use JavaLib [2] -- a .class file 
parser we maintain. We have put a lot of coding effort in 
reducing the memory consumption. We have implemented 
LocalVar , TVal" and Heap" as balanced binary trees, which, 
as well as being efficient, have easily allowed us not to store 
bottom values (NonNull and Def). This is specially impor- 
tant as non-reference type are coded as bottom and most 
variables are non-null. We use sharing extensively and func- 
tional programming has greatly helped us herein. E.g. the 
stack is implemented as a list and, between two instructions, 
the part of the stack that is unchanged by the instruction is 
shared in memory and, to some extent, the same applies to 
maps. Using sharing has also improved efficiency as it has 
then been possible to use physical equality tests instead of 
structural equality tests in some places. The result of the 



alias and instanceof analysis are compacted to remove the 
information for the instructions we know the results will not 
be used. E.g. for the result of the instanceof analysis, only 
the abstractions of stacks at conditional jumps (~ 5% of the 
instructions) are kept. 

5. EMPIRICAL RESULTS 

The benchmarks includes production applications such as 
Soot 2.2.4 [2S}, the JDT Core Compiler of Eclipse 3.3.3 [7J, 
Julia 1.4 [19], ESC/Java 2.0b4 [6] and Jess 7.1pl [18]. It also 
includes some other smaller applications such as JavaCC [17] . 
Jasmin [23], Tight VNC Viewer [28] and the 10 programs 
constituting the SPEC JVM98 benchmarks [25]. The imple- 
mentation used for those benchmarks is NIT 0.4, coded in 
OCaml 3.10.2 [21], and uses the JavaLib 1.7 [2] library. We 
performed the whole-program analysis with the Java Run- 
time Environment of GNU gcj 3.4.6 [13] on a MacBook Pro 
with a 2.4 GHz Intel Core 2 Duo processor with 4 GB of 
RAM. 

In our implementation, we have added switches to enable 
the modifications we have proposed in this article that may 
interact with the precision. The results obtained with all the 
modifications enabled are labeled as OPT and the version 
without modifications BASIC . Table [l] gives the number of 
annotations and the percentage of those which are non-null 
(@Raw or @NonNull) for field annotations, method parame- 
ters (except this) and method results. Notice the two in- 
ferences do not give the same number of annotations: the 
more precise the analysis is the more dead code is removed. 
The improvement between the two analyses is substantial: 
while BASIC inferred 41.5% of non-null annotations, OPT 
inferred 50.9% of non-null annotations, i.e. the improve- 
ment brought by OPT over BASIC represents more than 
9 points. Chalin and James experimentally confirmed [3] 
that at least two thirds of annotations in Java programs in 
general are supposed to be non-null. With regard to their 
experiment, 50.9% is already a significant fraction. 

The purpose of annotations is to reduce the number of 
potential exceptions, so we instrumented our inferencer to 
count the number of dereferences that were proved safe with 
the inferred annotations. Table [2] shows the percentage of 
safe dereferences over the total number of dereferences for 
field reads, field writes, method calls and array operations 
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2568 


90.9 
98.4 


19129 
19077 


67.0 
78.9 


1441 
1441 


54.3 
79.9 


33939 
33873 


63.0 
84.1 


Julia 


BASIC 
OPT 


4474 
4474 


75.6 
82.9 


1065 
1065 


90.0 
95.0 


15836 
15835 


72.2 
85.2 


987 
987 


39.9 
55.0 


22362 
22361 


72.3 
83.9 


Others 


BASIC 
OPT 


12341 
12341 


72.8 
79.3 


3295 
3295 


90.5 
93.4 


19189 
19182 


66.4 
76.4 


3182 
3182 


32.2 
62.7 


38007 
38000 


67.7 

77.7 


Total 


BASIC 
OPT 


104496 
104468 


76.2 
87.2 


26882 
26874 


91.1 
95.0 


230574 
230447 


67.5 
78.3 


25864 
25858 


34.9 
56.5 


387816 
387647 


69.3 

80.4 



Table 2: Dereferencing Results 







Space (MB) 


Time (s) 


Jess 


887 


144 


Soot 


634 


122 


ESC/Java 


421 


51 


Julia 


363 


44 


JDTCore 


331 


36 


JavaCC 


310 


34 


Others 


sum 


1642 


159 


max 


253 


30 



Table 3: Time and Space Consumption 



(load, store and length). Note how BASIC implementation 
was able to prove 2/3 of dereferences safe and how OPT 
reduced the number of unsafe dereferences by a 1/3, glob- 
ally proving more than 80% of dereferences in the studied 
benchmarks safe. 

Finally, Tab. [3] gives the memory and time consumption 
for the most expensive benchmarks and the sum and the 
maximum memory and time consumption for the other bench- 
marks for the OPT inferencer. Assuming enough processors 
and memory, the analyses can be run in parallel so the re- 
sources needed correspond to the sum of the memory con- 
sumption but the maximum of time consumption, while if 
the analyses are run sequentially, the resources needed are 
the maximum memory consumption but the sum of time 
consumption. The worst case is the analysis of Jess (804,111 
bytecode instructions including libraries and excluding dead 
code), which needs 887 MB and 144 s. Our results indicate 
that the implementation scales. 

6. RELATED WORK 

Fahndrich and Leino proposed the non-null type system |10] 
on which this analysis is transitively based. Papi et al. pro- 
pose a framework [24] for Java source code annotations and, 
as an example, provide a checker for non-null annotations 
based on [10] , Ekman et al. propose an plug-in [9] for Jas- 
tAdd 8 to infer and check the same non-null annotations. 
As their work predates the improvements we proposed in [16] 
and as we further improved the analysis in this paper, our 
analysis is strictly more precise. Fahndrich and Xia [11] 
propose another analysis to deal with object initialization 
which can deal with circular data structure but the gener- 



ality of their framework prevents the analysis from being 
as precise as our on examples without circular data struc- 
tures. Furthermore, their analysis can only infer a part of 
the annotations needed. 

To infer type annotations, Houdini [12] generates a set of 
possible annotations (non-null annotations among others) 
for a given program and uses ESC/Java [20] to refute false 
assumptions. CANAPA 5 lowers the burden of annotat- 
ing a program by propagating some non-null annotations. 
It also relies on ESC/Java to infer where annotations are 
needed. Those two annotation assistants have a simplified 
handling of objects under construction and rely on ESC/- 
Java [20] . which is neither sound nor complete. Some other 
work has focused on local type inference, i.e. inferring null- 
ness properties for small blocks of code like methods. One 
example hereof is the work of Male et al. [22] . Spoto very re- 
cently proposed another nullness inference analysis [27] with 
a different domain that expresses logical relations between 
nullness of variables. He compared his implementation with 
an old version of our tool NIT which did not include im- 
provements on precision and performance we made. We 
herein included in the benchmarks some of the programs 
used in |27] and we can notice that, despite the context sen- 
sitivity of the analysis in [27], both analyses have very close 
practical results. 

FindBugs [151 114] and Jlint [T| use static analyses to find 
null pointer bugs. To keep the false positive and false nega- 
tive rates low they are neither sound nor complete. 

7. CONCLUSION 

We have proposed an improved version of our provably 
sound inference analysis along with an efficient implementa- 
tion of both analyses. Despite being a whole-program anal- 
ysis, it is possible to infer annotations for production pro- 
grams within minutes. The precision of the analysis is not 
yet sufficient to certify existing code without handwork af- 
terwards, but it is still of interest for code documentation, 
for reverse engineering and for improving the precision of 
control flow graphs, which is useful to native code compilers 
and other program verifications and static analyses. 

While we still plan to further improve the inference analy- 
sis, we believe the need for a certified checker at the bytecode 
level is bigger than ever and hence this is in our priorities. 
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